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Abstract —  Automated  systems  to  perform  aircraft 
diagnostics  and  prognostics  are  of  current  interest. 
Development  of  those  systems  requires  large  amounts  of 
data  (collection,  monitoring,  manipulation)  to  capture  and 
characterize  fault  events,  and  to  ensure  data  is  captured 
early-on  in  a  fault  progression  to  support  prognostic 
system  development.  Continuous  data  collection  is  also 
required  to  capture  relatively  rare,  potentially  catastrophic 
events.  Data  collected  can  then  be  analyzed  to  assist  in 
the  development  of  automated  systems  and  for  continuous 
updating  of  algorithms  to  improve  detection, 
classification,  and  prognostic  performance.  A  test-bed  is 
being  developed  in  collaboration  with  the  US  Air  Force 
and  Army  to  perform  data  collection,  and  develop 
diagnostic  and  prognostic  processing  techniques  using 
Army  helicopter  vibration  and  engine  performance  data 
as  part  of  the  Army’s  Vibration  Management 
Enhancement  Program  (VMEP).  The  field  system  and  the 
testbed  being  developed  for  collection  and  processing  of 
VMEP  data  are  described  here. 
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1 .  Introduction 

The  US  Army  and  South  Carolina  Army  National  Guard 
(SCARNG)  are  currently  employing  the  Vibration 
Management  Enhancement  Program  (VMEP)  for 
helicopter  rotor  smoothing  and  vibration  monitoring. 
VMEP  is  an  automated  vibration  monitoring  and  fault 
diagnostic  tool  that  is  composed  of  three  primary 
components.  The  first  component  is  a  permanently 
installed  on-board  system  that  measures  and  processes 
vibration  and  parameter  information.  The  second 
component  is  the  PC-GBS  a  ground-based  Windows  ™ 
software  system  that  displays  recommended  maintenance 
actions  at  the  aircraft,  aircraft  status  to  the  maintenance 
manager,  and  measurement  details  to  the  engineer.  The 


third  component  is  a  system  of  web-based  tools  that 
provides  data  archiving,  software  configuration 
management,  management  reports,  and  an  advanced 
engineering  development  testbed. 

The  VMEP  objective  is  to  develop  a  low  cost  and 
effective  maintenance  tool  for  rotor  smoothing  (track  and 
balance)  and  vibration  monitoring.  It  is  believed  that  a 
significant  cost  savings  can  be  realized  with  a  system  that 
will  reduce  vibration  and  related  maintenance  test  flights. 
Further  cost  savings  are  expected  from  maintenance 
actions  taken  from  early  diagnosis  of  faults  prior  to 
significant,  in-flight  failures.  The  VMEP  system  has  been 
operational  on  18  AH-64A  and  8  UH-60L  aircraft  since 
September  2001.  The  VMEP  system  is  also  in  operation 
on  1  UH-60L  and  1  AH-64D  at  Ft  Rucker.  A  significant 
amount  of  vibration  data  has  been  collected  on  the 
airframe,  rotors,  engines,  drive  shafts,  gearboxes,  and 
accessories.  This  data  is  used  by  the  aircraft  maintainers 
for  corrective  actions  and  is  transmitted  via  the  Internet  to 
a  centralized  data  archive  and  analysis  system. 

This  paper  will  summarize  the  data  collected  and  will 
present  the  results  of  using  VMEP  to  perform  rotor 
smoothing  and  vibration  fault  diagnostics.  Case  studies  of 
fault  detection  events  will  be  presented.  The  Web  based 
data  analysis  and  data  fusion  tools  will  be  described  with 
examples  of  how  the  system  is  used  to  set  vibration  limits 
and  find  novelties.  Identification  of  novelties  is  a 
precursor  to  future  diagnostic  and  prognostic 
development  when  they  can  be  associated  with  specific 
system  faults  and  corrective  actions. 

2 .  Overview  of  The  Vibration 
Management  Enhancement  Program 

The  primary  function  of  the  VMEP  system  is  to  provide  a 
built-in  capability  to  perform  routine  vibration 
maintenance  functions  (such  as  rotor  smoothing  and 
mandatory  vibration  checks)  during  routine  operational 
flights.  In  addition,  the  system  monitors  the  status  or 
health  of  the  dynamic  drive  system  components  and  will 
record  engine  related  exceedances.  A  capability  for  flight 
regime  recognition  and  related  structural  usage 
monitoring 
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Figure  1  The  VMEP  on-board  system 


is  currently  being  added.  The  availability  of  advanced 
signal  processing  for  machinery  fault  diagnostics  allows 
much  of  the  processing  of  vibration  signatures  and  other 
monitoring  operations  to  be  completed  during  in-flight 
operation  of  the  aircraft.  The  VMEP  is  intended  to  detect 
faults  with  sufficient  lead-time  so  that  the  ground- 
maintainer  can  schedule  corrective  actions  well  before  the 
fault  becomes  an  in-flight  failure. 

Overall  system  description 

The  VMEP  system  consists  of  the  three  main  components 
described  below.  Specific  details  of  the  overall  VMEP 
system  can  be  found  in  [1,2]. 

On-board  system 

The  on-board  system,  shown  in  Figure  1,  consists  of  a 
Vibration  Management  Unit  (VMU),  a  wiring  harness, 
and  sensors.  The  VMU  front  panel  provides  the  aircrew  a 
simple  method  of  selecting  acquisitions  at  specific  flight 
conditions  and  receiving  system  status  information.  The 
sensors  include  tachometers  and  accelerometers 
distributed  throughout  the  helicopter’s  drive  train. 

The  data  acquisition  process  on  board  the  VMU  is 
configurable.  The  system  can  be  configured  for 
engineering  data  acquisition  or  for  day-to-day  data 
collection.  An  engineering  setup  may  include  collecting 
data  in  a  raw  format  like  a  digital  tape  recorder.  This 
allows  for  the  most  flexibility  in  post  processing.  In 


normal  day-to-day  operation  the  VMEP  is  setup  to  pre- 
process  the  data  and  only  store  condensed  Condition 
Indicators  (CIs)  in  small  compact  data  files. 

If  a  new  problem  is  found  in  a  mechanical  component,  a 
small  change  in  the  setup  file  can  be  made  to  allow  the 
VMEP  to  collect  raw  or  intermediate  results  for  detailed 
engineering  analysis. 

The  data  that  is  collected  and  processed  in  the  VMU  is 
stored  for  data  transfer  to  the  PC-GBS.  The  current  VMU 
has  96  Mbytes  of  non-volatile  memory  for  program  and 
data  storage.  A  typical  flight  contains  fewer  than  200 
Kbytes  of  data  allowing  450  typical  flights  to  be  stored 
before  the  data  needs  to  be  downloaded.  Typically  data  is 
downloaded  on  a  routine  bases  (daily,  weekly,  10hrs/14 
day)  at  the  operators  discretion.  The  typical  download 
process  only  takes  one  minute.  The  size  of  the  data  files 
can  be  changed  if  engineering  desires  more  raw  data  with 
the  pre-processed  Condition  Indicators. 

Ground  based  station 

The  ground-based  software  runs  on  a  PC  based  Windows 
platform.  The  system  is  referred  to  as  the  PC  Ground- 
Based  System  (PC-GBS).  The  operator  downloads  the 
processed  data  from  the  VMU  after  data  has  been 
captured  in  flight  via  a  serial  cable.  The  PC-GBS 
interprets  the  processed  data  and  presents  the  user  a  status 
of  the  aircraft  and  its  monitored  components  as  shown  in 
Figure  2. 
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Where  sufficient  data  is  known  about  a  specific  fault 
indicator,  the  instructions  are  provided  for  corrective 
action.  This  software  also  allows  the  trending  of  data 
across  time  for  a  specific  tail  number  or  across  the  fleet 
for  comparison  with  other  aircraft. 


Figure  2  VMEP  PC-Ground  Based  Station  -  Aircraft 
Status 

The  on-board  system  and  PC-GBS  are  a  continuous  data 
collection  system.  This  data  is  automatically  downloaded 
to  the  web  component  of  VMEP  whenever  the  PC-GBS  is 
attached  to  the  web  system. 

3 .  Rotor  Smoothing  results 

Introduction 

The  VMEP  system  is  permanently  installed  so  rotor 
smoothing  can  be  conducted  anytime  that  the  PC-GBS 
recommends  a  correction.  Data  is  collected  during  all 
flights  and  is  downloaded  to  the  PC-GBS.  This  enables 
the  users  to  keep  the  aircraft  smooth  between  major 
maintenance  events.  The  decision  to  make  adjustments  is 
up  to  the  maintenance  personnel  and  based  on  how  far  out 
of  tolerance  the  vibration  is.  On  the  PC-GBS  component 
status  is  shown  by  the  color  of  the  component’s  icon  as 
shown  in  Figure  3. 

Rotor  smoothing  typically  applies  to  main  rotors  (for  all 
aircraft),  tail  rotors  (for  all  aircraft  except  CH-47)  and 
some  drive  shafts  (UH-60  high  speed  shaft). 

Main  Rotor 

The  goal  of  main  rotor  smoothing  is  to  keep  the  in-plane 
(lateral)  and  out-of-plane  (vertical)  IP  vibrations  of  the 
main  rotor  at  a  minimum.  The  main  rotor  IP  vibration  is 


typically  measured  from  an  in-plane  and  an  out-of-plane 
accelerometer.  Adjustments  to  the  main  rotor  to  reduce 
these  vibrations  are  recommended  by  the  PC-GBS.  The 
default  solution  is  determined  by  the  following: 

The  rotor  smoothing  solution  always  tries  to  select  the 
least  amount  of  adjustments  to  get  the  best  reduction  in 
vibration.  The  reason  that  this  is  done  is  to  minimize  the 
chance  for  an  error  when  making  corrections,  which 
experience  has  shown  that  20%  of  adjustments  are  done 
incorrectly. 

If  data  was  collected  with  a  blade  tracker  installed  the 
track  data  is  used  to  select  the  best  solution  which  also 
optimizes  the  track. 

Main  rotor  smoothing  Maintenance  Test  Flights  (MTF) 
are  required  whenever  a  component  of  the  main  rotor 
system  has  been  adjusted  or  changed  (pitch  link,  rotor 
blade,  etc.).  During  MTF  the  main  rotor  vibration  is 
typically  reduced  below  the  goal,  which  is  indicated  by  a 
solid  green  icon  on  the  PC-GBS. 

Legend - 

O  Exceeded 
(J)  Caution 
(J)  Above  Goal 
Q  Good 

O  No  Data 

Figure  3  -  Aircraft  component  status 

Main  Rotor  adjustment  tweaks 

One  of  the  goals  of  VMEP  is  to  allow  rotor  smoothing 
tweaks  between  major  maintenance.  Before  the 
introduction  of  VMEP,  once  an  aircraft  was  released  from 
MTF  the  aircraft  would  be  flown  until  it  was  written  up 
for  high  IP  vibrations.  Typically  aircraft  would  fly  with 
high  main  rotor  vibrations  for  a  long  period  of  time.  Once 
the  aircraft  was  turned  over  to  maintenance,  test 
equipment  must  be  installed  and  a  dedicated  MTF  is 
required  to  smooth  the  main  rotor.  Now  that  VMEP  is 
installed  vibration  can  be  reduced  before  an  MTF  is 
required  due  to  high  vibrations.  After  the  aircraft  is 
release  from  MTF  the  main  rotor  component  on  the  PC- 
GBS  will  stay  green  for  some  time.  When  the  main  rotor 
vibration  is  above  the  goal,  which  is  indicated  by  a  green 
icon  with  an  exclamation  point  in  it,  the  PC-GBS  will 
recommend  a  solution  that  will  reduce  the  vibration.  This 
adjustment  is  called  a  tweak  between  major  maintenance. 
The  objective  is  to  allow  these  adjustments  without  a 
MTF  required.  These  tweaks  would  keep  the  aircraft 
smooth  between  major  maintenance  and  will  save  MTF’s 
for  rotor  smoothing.  These  adjustments  are  only  allowed 
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if  the  main  rotor  status  is  above  goal.  If  the  main  rotor 
status  is  yellow  (caution)  or  red  (exceedence)  a  dedicated 
MTF  for  rotor  smoothing  would  be  required.  A  MTF  is 
required  for  this  because  the  adjustments  that  would  be 
required  to  reduce  the  vibration  could  produce  excessive 
vibration  if  they  were  done  incorrectly. 

Tail  Rotor 

The  goal  of  tail  rotor  smoothing  is  to  keep  the  IP  in-plane 
vibration  at  a  minimum.  This  is  accomplished  by  adding 
or  subtracting  weights  to  balance  the  tail  rotor.  The  tail 
rotor  IP  vibration  is  measured  from  an  accelerometer  that 
is  in-plane  with  the  tail  rotor.  Adjustments  to  the  tail  rotor 
to  reduce  the  in-plane  vibration  is  recommended  by  the 
PC-GBS.  Tail  rotor  vibration  is  monitored  on  all  flights. 

A  dedicated  rotor  smoothing  MTF  is  required  whenever  a 
component  of  the  tail  rotor  system  has  been  adjusted  or 
changed  (pitch  link,  rotor  blade,  etc.).  During  MTF  the 
tail  rotor  vibration  is  reduced  below  the  goal,  which  is 
indicated  by  a  solid  green  icon  on  the  PC-GBS. 

The  goal  to  reduce  vibration  between  major  maintenance 
on  the  tail  rotor  is  achieved  by  allowing  adjustment 
tweaks  as  described  in  the  Main  Rotor  section  above. 

Engine  High  Speed  Shaft  (HSS)  Balance  (UH-60  only) 

The  engine  HSS  on  the  UH-60  requires  balancing.  Due  to 
the  criticality  of  keeping  the  HSS  vibrations  low,  a  hard 
limit  is  used  that  the  shaft  must  be  below.  If  this  shaft 
requires  balancing  the  PC-GBS  will  direct  the  user  to 
collect  the  data  to  balance  the  shaft.  Once  the  data  is 
collected  the  PC-GBS  will  recommend  the  addition  or 
subtraction  of  washers  to  reduce  the  vibration  below  the 
limit. 

Rotor  Smoothing  Algorithms 

A  general,  neural  network  based  algorithm  has  been 
developed  and  applied  to  the  problem  of  helicopter  rotor 
smoothing.  This  approach  provides  non-parametric 
mappings  between  the  spaces  of  rotor  adjustment  and 
vibration  measurements,  which  are  derived  directly  from 
empirical  data,  and  permits  to  relax  the  usually  used 
linearity  assumption.  Additionally,  the  rotor  smoothing 
solutions  are  optimized  to  minimize  the  number  of 
required  adjustment  moves.  [3] 

Tools  for  Rotor  Smoothing 

The  PC-GBS  has  polar  charts  that  display  the  rotor 
smoothing  vibrations  and  also  indicates  where  the 
vibration  should  move  to,  based  on  the  current  set  of 
adjustments  as  shown  in  Figure  8  for  the  main  rotor 
smoothing  example.  These  polar  charts  can  also  be 


utilized  to  determine  the  health  of  the  rotor.  The  PC-GBS 
will  direct  the  operator  to  view  the  polar  chart  if  the 
solution  is  not  reducing  the  vibration  to  a  satisfactory 
level  (check  the  health  of  the  rotor). 

The  PC-GBS  has  trending  polar  charts  that  are  used  to 
plot  the  vibration  from  one  flight  to  the  next  to  determine 
the  affects  that  the  adjustments  had  on  the  vibration  as 
shown  in  Figure  10  for  the  tail  balance  example.  The  PC- 
GBS  will  recommend  a  review  of  this  display  if  the 
vibration  did  not  move  in  the  correct  direction  (the  wrong 
move  was  made). 

Whenever  the  PC-GBS  recommends  a  solution  there  are 
hot  links  that  are  associated  with  each  type  of  adjustment. 
When  the  link  is  selected  it  takes  the  user  to  the  procedure 
on  how  to  perform  this  adjustment.  Figure  4  shows  an 
example  of  the  instructions  for  an  AH- 64  tail  rotor. 


Figure  4  -  Instructions  for  Rotor  Smoothing 
Adjustments 

The  PC-GBS  has  a  data  quality  indicator  for  each  test 
state  that  rotor  smoothing  data  was  collected.  This  gives 
an  indication  of  the  stability  of  the  vibration  measurement 
(amplitude  and  phase)  for  the  duration  of  the  synchronous 
average.  If  the  data  quality  indicator  is  low  for  a  test  state 
there  is  an  option  in  the  PC-GBS  to  not  include  this  test 
state  in  the  solution.  By  using  the  data  quality  indicator 
and  the  polar  chart  display  it  can  be  determined  if  a  test 
state  should  be  excluded  from  the  rotor  smoothing 
solution.  The  Data  Quality  indicator  is  shown  in  Figure  6. 

Main  Rotor  Smoothing  Example 

To  illustrate  the  rotor  smoothing  process  the  following 
example  from  a  recently  smoothed  AH-64A  aircraft  tail 
number  86-09013  at  South  Carolina  Army  National 
Guard  (SCARNG)  is  shown. 

First  vibration  data  from  the  rotor  smoothing  flight  is 
downloaded  to  the  PC-GBS  where  the  maintainer  is 


presented  with  the  status  of  the  Main  Rotor  Smoothing 
component.  If  the  status  is  anything  other  than  solid  green 
(meaning  vibration  levels  are  above  goal),  the  user  will 
select  the  component  to  view  the  corrective  actions  as 
shown  in  Figure  5.  For  this  example  the  user  selected  the 
flight  from  5  February  2003  at  14:07:17  where  the  aircraft 
was  in  Exceedance  due  to  high  main  rotor  vibrations.  In 
the  corrective  action  area,  the  default  solution  is 
presented.  This  is  the  adjustment  that  was  made  to  the 
aircraft. 


Figure  5  -  Aircraft  Status  Summary 

To  view  more  details  and  to  make  changes  to  the 
adjustments  the  user  can  select  the  flight  and  is  presented 
with  the  dialog  shown  in  Figure  6.  Here  the  measured 
vibrations  and  predicted  vibrations  are  shown  based  on 
the  current  rotor  smoothing  solution.  For  this  example  the 
predicted  in  flight  vibrations  were  below  goal,  which 
reinforced  the  application  of  the  default  solution. 

If  the  user  desires  to  change  the  rotor  smoothing  solution 
because  an  adjustment  can  not  be  made  (weights  or  tabs 
are  at  a  maximum)  the  Rotor  Smoothing  Solution  Tab  can 
be  selected  and  is  shown  in  Figure  7.  There  are  many 
options  to  customize  the  solution  such  as  resolve  to  limit 
and  limiting  adjustments.  The  users  can  also  manually 
enter  an  adjustment  and  view  the  predictions.  These 
features  are  normally  used  for  difficult  to  smooth  aircraft 
as  the  default  solution  shown  in  Figure  7  is  sufficient.  For 
this  aircraft  the  solution  was  not  modified  because  the  tab 
move  could  be  made. 

To  view  the  measured  vibrations  and  predictions  based  on 
the  current  solution  the  user  selects  the  Vibration  Plot  as 
shown  in  Figure  8.  A  polar  chart  shows  vibration  levels 
as  a  distance  from  the  center  of  the  chart  (the  center  being 
zero  vibration).  The  phase  of  the  polar  chart  is  the  spatial 
relationship  between  vibration  and  a  location  on  the  rotor. 
The  objective  of  the  algorithm  is  to  move  all  of  the 
vibration  points  to  the  center  of  the  polar  chart.  The 
vibration  limits  are  shown  as  dashed  circles  and  serve  as  a 


target.  This  plot  is  useful  for  troubleshooting  difficult  to 
smooth  aircraft.  Sometimes  the  points  are  spread  around 
the  polar  plot  and  an  optimum  solution  for  all  vibration 
points  is  difficult  to  achieve.  In  this  example  aircraft  the 
points  were  grouped  and  the  solution  drove  the  vibration 
towards  center  as  shown  in  Figure  8. 


Figure  6  -  Rotor  Smoothing  Vibration  Values 


Figure  7  -  Rotor  Smoothing  Adjustments 
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Figure  8  -  Rotor  Smoothing  Polar  Plot 

A  tracker  was  installed  during  data  collection  on  this 
aircraft  therefore  a  Track  tab  is  available  on  the  vibration 
adjustment  screen.  To  view  the  track  data  the  user  selects 
the  track  tab  as  shown  in  Figure  9.  The  user  can  view  the 
effects  of  the  current  adjustments  on  track  by  comparing 
the  measured  track  (top  display)  to  the  predicted  track 
(bottom  display).  Other  track  data  is  available  for  display 
such  as  lead-lag.  For  this  aircraft  the  recommended 
adjustment  to  blade  4  (red)  moved  the  blade  up  thus 
improving  track  while  reducing  vibration. 


had  all  vibrations  below  goal.  Table  1  shows  the 
measured  and  predicted  vibrations  from  the  first  flight 
with  the  measured  vibrations  from  the  second  flight. 


Table  1 


State 

Sensor 

Flight  1 
IPS 

Predicted 

IPS 

Flight  2 
IPS 

FPG100 

Lat 

.25 

.25 

.17 

Hover 

Lat 

.06 

.04 

.03 

60K 

Vert 

.15 

.21 

.21 

80K 

Vert 

.41 

.12 

.13 

100K 

Vert 

.62 

.09 

.19 

120K 

Vert 

.68 

.03 

.18 

140K 

Vert 

.81 

.05 

.17 

Tail  Rotor  Smoothing  Example 

To  illustrate  the  tail  rotor  smoothing  process  the 
following  example  from  a  recently  smoothed  UH-60L 
aircraft  tail  number  92-26415  at  South  Carolina  Army 
National  Guard  (SCARNG)  is  shown. 

First  vibration  data  from  the  tail  rotor  ground  run  is 
downloaded  to  the  PC-GBS  where  the  maintainer  is 
presented  with  the  status  of  the  Tail  Rotor  Balance 
component.  For  this  example  the  tail  rotor  started  out  on 
6/14/2002  with  below  goal  vibrations  of  0.20  IPS.  The 
vibrations  increased  over  time  to  a  maximum  level  of 
0.23  IPS  at  which  time  the  maintainers  decided  to  make 
an  adjustment.  The  default  solution  of -29  grams  from  the 
target  quadrant  was  applied  to  the  aircraft  on  8/13/2002. 
The  results  from  this  adjustment  are  shown  in  Table  2. 


Table  2 


State 

Sensor 

Run  1 
IPS 

Predicted 

IPS 

Run  2 
IPS 

FPG100 

Tail 

.23 

.00 

.02 

The  vibrations  from  tail  rotors  increase  over  time.  A 
current  Army  procedure  has  tail  rotor  balance  checks 
every  100  hours.  By  having  VMEP  installed  the 
vibrations  can  be  kept  at  a  minimum.  A  trend  chart  which 
shows  the  progression  of  vibration  levels  over  time  is 


Figure  9  -  Rotor  Smoothing  Track  Display 

The  default  correction  was  applied  to  the  aircraft.  Blade  4 
tab  sections  6-10  were  bent  up  1  degree.  The  next  flight 
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illustrated  in  Figure  10.  The  points  A,  B  and  C  show  the 
progression  over  time  with  out  any  adjustments  being 
made.  The  reduction  in  vibration  from  the  default 
adjustment  is  shown  as  the  points  go  to  the  center  from  C 
to  D.  After  the  adjustment  was  made,  the  vibrations  will 
continue  to  increase  as  shown  in  the  points  from  D  to  E  to 
F. 


Figure  10  -  Polar  Trend 
4.  FAULT  DETECTION  EVENTS 

Loose  Gearbox  Mount 

AH-64A  aircraft  tail  number  86-09002  was  operational  at 
SCARNG.  A  VMEP  data  download  on  15  August,  2001 
showed  caution  level  vibrations  from  the  Tail  Swashplate 
accelerometer.  The  Cl  plot  and  the  corresponding  fault 
summary  display  is  shown  in  Figure  1 1 . 


Figure  11  -  Loose  Gearbox  Mount  Cl  display 
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A  visual  inspection  of  the  tail  gearbox  revealed  that  the 
mount  link  shown  in  Figure  12  was  loose  with  a 
considerable  amount  of  end-play  in  the  tumbuckles.  The 
mount  was  re-torqued  to  within  specifications,  and  the 
resulting  vibrations  were  reduced  from  14.07  Gs  to  2.23 
Gs. 


Figure  12  -  AH-64  Tail  Gearbox  Mount 

Driveshaft  Vibrations 

AH-64A  Aircraft  86-08992  from  SCARNG  had  a  good 
“green”  aircraft  status  when  it  went  into  phase 
maintenance  in  October  2001.  When  the  aircraft  came  out 
in  March  of  2002,  the  VMEP  system  noted  above  caution 
level  “yellow”  indicators  for  the  tail  rotor  drive  shaft 
component.  The  aft  hanger  bearing  drive  shaft  1R 
component  increased  from  around  1.0  IPS  to  2.5  IPS  as 
shown  in  Figure  13.  The  aft  hanger  bearing  was  changed 
with  no  effect  on  vibrations.  The  aft  hanger  bearing 
accelerometer  was  checked  and  found  to  be  OK.  The 
drive  shaft  was  then  removed,  inspected  and  re-installed 
swapping  directions  end-for-end.  The  resulting  vibrations 
were  reduced  to  below  caution  levels. 


Multiple  CIs  Over  Time 

AH 64:86-08992  from  01/01/1995  00:00:00  to  03/01/2003  00:00:00 


Jul  Od  Jan  2002  Apr  Jul  Od 

2001  Calendar  Time 


Figure  13  -  AH-64  Driveshaft  Vibrations 

The  helicopter  maintainers  in  South  Carolina  realize  the 


significance  of  fault  detection.  This  information  is  used 
during  the  lOhour  /14  day  PMS  to  better  inspect  their 
aircraft.  When  the  VMU  data  is  downloaded,  the  crew 
chief  is  interested  in  trended  vibration  data.  He  wants  to 
know  what  areas  of  his  aircraft  show  increased  vibration 
levels.  He  then  more  carefully  looks  at  this  area  to  try  and 
locate  a  problem.  On  several  occasions  the  crew  chief  has 
been  successful  in  either  correcting  or  replacing  a  small 
item  thus  savings  a  larger  more  expensive  item. 


These  conditions  are:  nominal  operation;  operation  with 
known  faults;  and,  most  importantly  for  prognostics, 
operation  leading  up  to  the  time  that  a  fault  can  be 
detected.  Typically,  data  is  saved  only  when  a  fault  is 
detected;  too  late  to  be  useful  for  prognostics 
development. 

Figure  14  shows  the  hardware  and  connectivity  of  the 
system  used  to  perform  data  collection.  The  VMU 


The  Army  National  Guard  maintainers  in  South  Carolina 
believe  that  this  fault  detection  will  not  only  prevent 
major  in-flight  catastrophic  failures  but  will  provide  the 
supporting  documentation  to  safely  extend  the  flight  time 
between  inspections. 

5 .  VMEP  Web  Server 

Connectivity 

The  VMEP  system  includes  an  internet  utility  to  collect, 
analyze,  and  make  available  data  from  the  PC-GBS 
located  at  the  unit/aircraft.  The  successful  development  of 
algorithms  for  helicopter  condition  health  monitoring 
requires  real  data  that  represent  specific  conditions. 


collects  vibration  and  1553  (VMEP  plus  configuration) 
data.  Maintenance  personnel  download  the  data,  via  serial 
port,  to  a  PC-GBS,  which  is  typically  a  ruggidized  laptop 
computer. 

Data  is  then  transferred  to  the  VMEP  Server 
automatically  when  the  PC-GBS  and  server  are 
connected.  Agent  based  software  detects  if  new  files  exist 
on  the  PC-GBS  that  do  not  exist  on  the  server.  If  not,  that 
data  is  automatically  sent. 

Users  that  do  not  have  the  PC-GBS  can  also  have  access 
to  data  and  results  using  a  standard  web  browser 
interface. 
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Users: 


-  PC-GBS:  Maintenance 

-  Browser:  Maintenance  Support 

Management 
Outside  engineering 


iMDy  Do v 3 r*j p i iVii r i f 


Engineering  Team 


Other  Applications: 
-Data  Mining  (CART) 
-Bayesian  Networks  (Hugin) 


◄ - ► 


Matlab 
-User  interfaces 
-Diagnostics  and 
Predictive  Diagnostic  Upgrade 
-  Future  Algorithm  Development 


Figure  15  VMEP  Server  functional  overview 


Functional  flow  of  VMEP  Server 

Figure  15  shows  an  overview  of  the  functional  flow  of  the 

VMEP  Server  system.  There  are  two  major  components 
to  that  system  as  indicated  in  the  figure.  The  first  is  the 
VMEP  Server  itself  As  described  above,  the  VMEP 
Server  is  the  central  data  repository  for  collection  and 
organization  of  all  aircraft  collected  data.  This  processing 
is  handled  by  the  Automated  Data  Archive  in  the  Server. 

Network  Security  is  performed  using  a  secure  internet 
connection  and  password  protection  to  access  the  system. 
The  user  /  password  are  context  sensitive  so  that  user’s 
will  only  be  able  to  access  those  components  of  the  web 
system  for  which  they  are  authorized. 

Aircraft  Configuration  and  Software  Updates  for  the  PC- 
GBS  and  VMU  are  stored  on  the  VMEP  Server  and 
automatically  transferred  during  WEB  connection  using 
Configuration  Control.  The  updates  are  first  transferred  to 
the  PC-GBS  and  then  onto  individual  aircraft  on-board 
systems  as  opportunities  arise  (i.e.  when  maintenance 
personnel  interface  a  PC-GBS  to  a  specific  tail  number 
VMU).  Configuration  control  will  inform  maintenance  if 
too  much  time  has  passed  between  the  time  an  upgrade  is 
posted  and  it  has  not  been  transferred  to  a  specific  tail 


number.  All  the  maintainer  needs  to  do  is  attach  a  PC- 
GBS  with  the  updates  to  the  on-board  system  that  does 
not  have  the  updates. 

A  most  useful  portion  of  the  Server  for  maintenance  is  the 
Fleet  Statistics  &  Reports  section.  Here,  fleet  data, 
statistics,  trending,  and  summary  reports  are  available. 
These  reports  are  available  down  to  individual  tail 
number  and  component  level. 

Electronic  ’Help*  is  available  in  the  form  of  electronic 
user's  manuals,  power  point  training  presentations,  and 
FAQs. 

Advanced  engineering  contains  a  variety  of  modules  to 
analyze  the  incoming  data.  These  include  Diagnostics, 
Prognostics,  and  Novelty  Detection. 

Diagnostics  and  prognostics  algorithms  are  designed  to 
respond  to  known  fault  conditions.  A  novel  event  is  an 
unknown  off-nominal  condition.  That  is,  the  novel  event 
is  not  nominal  nor  is  it  classified  in  any  of  the  known 
fault  conditions.  It’s  something  completely  new. 

Novelty  detection  is  an  important  component  in  the 
operation  of  the  Server.  All  incoming  data  is  screened  to 
detect,  set  aside,  and  flag  for  engineering  analysis 
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anomaly  events.  Engineers  will  not  have  to  continuously 
examine  “normal”  events.  Rather  only  “interesting” 
events  need  be  examined.  It  is  these  sorts  of  events  that 
are  on  the  edges  of  the  data  distributions  between  normal 
and  fault  that  are  of  the  most  interest  for  developing 
prognostic  algorithms. 

The  second  component  of  the  Server  is  the  intelligent 
Machinery  Diagnostics  System  (iMDS)  development 
system.  The  iMDS  Development  system  is  a  “behind  the 
scenes”  set  of  tools  used  by  diagnostic  engineers.  It 
contains  tools  for  performing  advanced  engineering 
analysis  on  data  stored  on  the  Server  and  elsewhere.  The 
toolkit  allows  engineers  to  prototype  algorithms  that  can 
later  be  incorporated  into  upgrades  for  the  PC-GBS  and 
on-board  systems. 

iMDS  Development  is  standalone  from  the  other  VMEP 
Server  system  components;  however,  it  has  the  ability  to 
download  and  process  data  from  the  iMDS  Server. 
Details  of  the  iMDS  Development  system  can  be  found  in 

[2,7]. 


6.  VMEP  Server  Operation  -  Examples 

Figure  16  shows  the  opening  screen  the  user  sees  when 
entering  the  VMEP  Server  via  the  browser  interface. 
There  are  5  major  links  from  the  home  page. 

Fleet  Analysis  is  designed  for  the  maintainer  and 
maintainer  support  personnel.  It  contains  graphical 
summaries  of  fleet  status  as  well  as  details  of  individual 
aircraft,  aircraft  component,  and  individual  condition 
indicator  (Cl)  status.  Configuration  control  of  VMEP 
software  releases  is  also  included. 

Advanced  Engineering  is  designed  for  engineers.  It 
allows  for  visualization  of  data  sets,  selection  and 
labeling  of  ‘normal’  and  ‘fault’  representative  data  sets, 
setting  of  individual  component  Cl  detection  thresholds, 
and  development  of  models  for  diagnostics,  prognostics, 
and  anomaly  detection. 


mt>s  * 

Intelligent 

Machinery  diagnostics 

System 

1  AC 

home  fleet  analysis 

advanced  enqineerinq  download 

related  links 

support 

site  map 

What's  New! 


Bug  Report 


Fleet  Analysis 

•  Fleet  Overview 

•  Aircraft  Status  by  tail  number 

•  Reports 

g  Flight  Data  Report 
o  Status  Reports 

•  Plots 

o  Condition  Indicator  Time  Trend 

o  Condition  Indicator  Tail  Trend 

•  Configuration 


Related  Links 

•  AeroMechanics  web  site 

.  JAC 

•  National  Guard 

Support 

•  Technical  Assistance 

•  FAQ 

•  Bug  Report 

•  User  Manuals 


Advanced  Engineering 


Download 


•  Fleet  Statistics 

•  Anomaly  Detection 

•  Database  Statistics 


•  Programs 

•  Data 

•  User  Manuals 


home  |  fleet  analysis  |  advanced  engineering  |  download  |  related  links  |  support  |  site  map 


Figure  16  VMEP  Server  Browser  Interface 
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Download  contains  the  latest  releases  of  both  the  PC- 
GBS  and  on-board  system  software  as  well  as  archived 
data  and  the  latest  VMEP  related  user  manuals. 

Support  contains  links  to  FAQ’s,  a  bug  reporting 
mechanism,  and  aircraft  (non- VMEP)  related  user’s 
manuals. 

Related  Links  contain  links  to  other  websites  that  may  be 
of  interest  to  the  user. 

Fleet  Analysis 

Whenever  possible,  visualization  of  data  processing 
results  and  summaries  have  been  used  in  the  Server.  The 
browser  interface  uses  all  the  standard  pull  down  menus, 
'back’  button,  and  hyperlinks  familiar  to  users.  'Fleet 
Analysis'  is  the  main  summary  page  used  by  maintenance 
and  fleet  maintenance  support  personnel.  Figure  17  shows 
a  sample  screen  that  is  available  from  Fleet  Overview. 


Aircraft  Status  Total  Aircraft 

AH64  52%  24%  21 


Component  Status  Total  Count 

Accessories  [  100%  20 

APU  |  100%  20 

Drive  Shafts  15%  85%  20 

Engine  1  5%  95%  20 

Engine  2  ^5%  90%  20 

Intermediate  Gearbox  |  21%  79%  19 

Main  Gearbox  5%  95%  20 

Main  Rotor  ■  35%  60%  20 

Nose  Gearbox  1  5%  95%  20 

Nose  Gearbox  2  JlO%  85%  20 

Tail  Gearbox  5%  95%  19 

Tail  Rotor  30%  55%  20 

VMU  |  35%  65%  20 

|  Exceedance  Status  |  Caution  Status  |  Good  Status 

Figure  17  Fleet  Overview  example 

The  figure  shows  at  the  top  a  summary  status  for  all 
AH64  aircraft  at  a  unit;  of  the  2 1  aircraft  being  monitored 
24%  have  at  least  one  component  that  has  a  red  (in 
exceedance)  status,  52%  are  Yellow  (or  caution)  status, 
and  24%  are  Green  (good)  status.  The  numbers  / 
percentages  shown  here  are  for  demonstration  purposes 
only.  Note  this  is  not  a  complete  data  set,  rather  selected 
tails  /  times  to  give  a  good  demonstration. 

Details  on  which  are  the  troublesome  components  can  be 
found  in  the  bottom  portion  of  the  display.  Here  we  see 
that  the  Tail  Rotor  is  the  most  troublesome  with  15%  of 
the  aircraft  having  tail  rotor  vibrations  in  exceedance  of 


the  specified  levels.  Additional  details  can  be  found  by 
clicking  on  the  Tail  Rotor  hypertext  to  bring  up  all  of  the 
CIs  computed  for  the  tail  rotor.  A  similar  bar  graph 
summary  display  is  presented.  The  Cl  level  information 
further  isolates  problematic  areas. 

The  Fleet  Analysis  window  also  allow  maintenance  and 
maintenance  support  to  quickly  see  what  the  readiness  of 
all  /  or  specific  type  aircraft  at  a  unit  or  across  the  fleet  is. 
The  most  troublesome  components  and  the  faults 
associated  with  them  can  quickly  be  identified. 

Figure  18  shows  an  example  of  the  detail  available  when 
Aircraft  Status  by  Tail  Number  is  selected.  A  tree 
structure  similar  to  a  Windows  Explorer  tree  is  brought 
up.  That  tree  can  be  expanded  /  collapsed  to  supply  the 
user  with  the  detailed  required. 

€3 

National  Guard 
4D-  U  SCARNG 
AH64 
1  H  6  0 

91-26326 
91-26328 
}  -■#  «ti  sortaer 
\  -<£'  Act  GBX 1 
|  Acc  GBX  2 

| . O  Accessories 

f . ■#  Engine  1 

f . ■#  Engine  2 

| . ■#  Input  GBX  1 

| . ■€>  Input  GBX  2 

[ . #  Inter  GBX 

| . •€>  Main  GBX 

i . <D  Main  Rotor 

I  i  f . ♦  Oil  Cooler 

Figure  18  Aircraft  Status  example 

Red,  yellow,  and  green  colors  are  again  used  in  the  icons 
to  indicate  the  current  status  of  all  the  aircraft  at  a  given 
point  in  the  tree.  Green  means  everything  is  within 
tolerance.  Red  means  that  some  component  is  out  of 
tolerance.  Yellow  indicates  that  the  component  is  in  a 
'warning'  band  and  requires  close  monitoring.  For 
example,  in  Figure  18  at  least  one  of  the  AH64s  has  a  red 
status  while  at  least  one  of  the  UH60  has  yellow  status. 
The  tree  has  been  expanded  to  show  that  for  a  particular 
UH60  tail  number,  the  component  that  leads  to  the 
caution  status  is  due  to  the  Main  Rotor. 

Advanced  Engineering 

Advanced  Engineering  is  intended  for  the  more 
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sophisticated  engineering  user.  Currently,  Advanced 
Engineering  includes: 

o  Database  statistics 
o  Fleet  statistics  and 
o  Anomaly  detection. 

Figure  19  shows  an  example  of  the  output  obtained  when 
the  user  selects  Database  Statistics  from  the  Advanced 
Engineering  window.  The  example  shows  all  the  data  that 
has  been  stored  for  all  AH64  aircraft  to  date.  As  shown,  a 
total  of  857  data  sets  has  been  collected  which  contain 
8750  CIs  that  have  been  found  from  that  data.  This  is 
really  not  nearly  enough  if  we  want  to  use  real  data  to 
specify  a  10"5  false  alarm  threshold. 

Aircraft  type:  AH64 


Mode 


Number  of  Number  of 
Data  Sets  CIs 


BIT 

2532 

2532 

FLIGHT 

518 

23545 

GNDBAL 

157 

142 

MONITOR 

1583 

11023 

SURVEY 

136 

47 

TAIL 

166 

155 

TRACK 

178 

168 

Totals 

5270 

37612 

Figure  19  Database  statistics  for  AH-64 


Fleet  Statistics  brings  up  a  display  that  compares  single 
component  -  single  Cl  for  a  particular  tail  number  to  all 
aircraft  within  the  fleet.  Similar  to  the  Aircraft  Status 
summary  tree,  Fleet  Statistics  summary  for  all  the  CIs  can 
be  obtained  through  a  similar  tree. 

On  Figure  20,  the  left  side  shows  the  Fleet  Statistics 
summary  /  selection  tree  expanded  to  highlight  specific 
tail  number  86-08996.  For  that  tail,  the  current  condition 
is  Red  (there  is  a  component  in  exceedance  that  is  not 
shown).  The  individual  components  indicate  that  Engine 
2  vibrations  are  in  the  Yellow  /  caution  limit  and  that  the 
Cl  labeled  SP2  FPG100  #2  Eng  GG  gives  rise  to  the 
caution. 

The  right  hand  side  of  Figure  20  shows  a  box  plot 
summary  of  the  selected  tail  /  component  /  condition 
indicator  compared  to  that  Cl  found  for  ah  AH64  aircraft. 

A  box  plot  summarizes  the  Cl  data.  It  indicates  the 
median,  upper  and  lower  quartile ,  upper  and  lower 
adjacent  values ,  and  outlier  individual  points.  The 
boxplot  in  Figure  20  is  broken  down  as  follows.  The  large 
dot  in  the  plot  shows  the  median  (middle  point  value)  of 
the  data.  The  ‘box’  is  drawn  so  that  50%  of  the  data  will 
reside  inside  the  box.  25%  of  the  data  is  to  the  left  of  the 
box  and  25%  is  to  the  right  of  the  box.  The  dotted  lines 
are  called  fences  or  gates.  The  gates  are  sort  of  a  poor 
man’s  single  Cl  anomaly  detector;  if  the  data  is  well 
behaved  all  the  points  should  fall  between  the  gates. 
Outlier  points  are  plotted  as  individual  circles  outside  the 
gates. 


■B-jjfc  86-08963  H 

-EH!  86-08964 
86-08986 
-EJ-^f  86-08992 
E}-i!  86-08993 
EH$  86-08996 
El#  Accessories 
E}-#  APU 
E}<D  Drive  Shafts 
EJ-#  Engine  1 
EKI)  Engine  2 

•<D  SP2  FPG1 00  #2  Eng  GG 
O  SP2  FPG1 00  #2  Eng  PT 
O  SP4  FPG1 00  #2  ENG  OA 
EKD  Intermediate  Gearbox 


Cl  Plot 

Aircraft  Type:  AH64 
Tail  Number(s):  86-08996ALL  AH64 
Component:  Engine  2  Status:®  # 
SP2  FPG1QQ  #2  Ena  GG 


86-08996 

- 1 - 1 - 1 - 

O 

- 1 - 1 - 1 - 

i-Q-i 
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Figure  20  Advanced  Engineering  Fleet  Statistics  example 
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Aircraft  Type:  AH64 
Tail  Number:  86-08996 
Component:  Engine  2 


SP2  FPG1 00  #2  Eng  GG 
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Figure  21  Anomaly  Detection  example 


In  Figure  20  we  see  that  the  points  associated  with  the 
selected  tail  number  are  self  consistent.  For  the  most  part 
(with  the  exception  of  a  0  value)  they  all  lie  with  in  the 
blue  box  plus  gates.  However  it  is  easily  seen  in  the 
display  that  as  a  group,  they  are  very  different  from  the 
same  Cl  calculated  from  all  the  other  aircraft  in  the 
database. 

Anomaly  Detection 

Up  to  this  point,  each  of  the  CIs  has  been  handled  as 
single  variables.  Fusing  information  from  several  CIs  will 
take  advantage  of  the  relationships  of  CIs  in  order  to 
improve  component  level  processing. 

There  are  a  variety  of  anomaly  detectors  (ADs)  that  can 
be  used  for  the  problem  [4].  On  the  Server  we  use  a 
neural  net  solution  to  the  problem  [5].  The  basic  neural 


net  anomaly  detector  uses  radial  basis  function  (RBF) 
neural  nets  to  form  a  statistical  model  of  “nominal”  data. 
As  new  data  enters  into  the  system,  it  is  compared  to  the 
RBF  neural  net  model.  If  data  falls  within  the  boundaries 
defined  by  that  model,  then  it  is  flagged  as  “nominal”.  If 
is  does  not,  then  it  is  flagged  as  an  “anomaly”.  In  the  web 
site  several  different  anomaly  detectors  are  implemented 
using  not  only  the  RBF  neural  network,  but  Support 
Vector  Machines  and  Fuzzy  Logic.  The  user  can  call  up 
the  different  detectors  from  a  pull  down  window. 

Notice  that  there  is  an  implicit  Gaussian  assumption  in  the 
AD  as  implemented  using  the  RBF  neural  network.  In 
order  to  visualize  distribution  of  the  multi-CI  data  we 
have  created  sets  of  2-dimensional  plots  (one  for  each 
pair  of  CIs)  to  see  how  the  CIs  are  related  and  to 
determine  if  the  model  fit  is  appropriate.  Figure  21  shows 
an  example  of  that  plot  for  the  Engine  #2  on  the  AH64 
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aircraft. 


Set  Ci  Limits 


The  Engine  #2  component  has  3  CIs  associated  with  it. 
Thus  there  is  the  3  x  3  array  of  plots  shown  in  Figure  21. 
The  plots  correspond  to  pairs  of  CI  values  for  the  off 
diagonal  plots.  The  plots  along  the  main  diagonal  are 
histograms  for  the  corresponding  CI.  Note  that  the  scales 
on  the  plots  are  different  depending  on  what  is  being 
plotted.  The  CI  values  plotted  are  labeled  at  the  top  and 
sides. 

The  CI  that  was  flagged  in  the  single  CI  case 
corresponded  to  tail  number  86-08996.  Those  points 
stand  out  as  a  cluster  in  two  dimensions  in  the  figure.  For 
anomaly  detection  purposes,  those  points  were  labeled  as 
“good”  along  with  all  the  other  green  points  shown  in  the 
plot.  A  neural  net  model  was  built  using  those  green 
points.  Two  outliers,  identified  as  the  red  points,  were 
found  by  the  anomaly  detector. 

Single  CI  Detection  Threshold  Setting 

Initial  settings  for  single  CIs  on  the  Server  have  either 
been  set  based  on  the  original  manufacturers 
specifications  or  by  engineering  judgment  as  to  what  is 
acceptable  or  not.  Since  a  substantial  amount  of  data  for 
Army  aircraft  has  been  collected,  the  website  has 
included  an  automated  statistics  based  setting  for  the 
various  thresholds  of  single  CIs.  The  automated  setting  of 
thresholds  is  based  on  ordered  statistics  of  the  data. 

Figure  22  shows  an  example  of  that  page  for  the  AH64 
Drive  shafts  for  single  CI  threshold  setting.  There  are  four 
CIs  associated  with  that  component  but  only  two  are 
shown  in  the  figure  (the  user  would  scroll  down  on  the 
website  for  the  other  two).  The  current  and  suggested 
values  of  the  ‘goal’  (green),  ‘caution’  (yellow),  and 
‘exceedance’  (red)  are  shown. 

The  Recommended  Settings  are  found  directly  from  the 
collected  normal  data  using  the  box  plot  processing 
similar  to  that  described  before.  Figure  22  indicates  that 
the  Recommended  Settings  for  the  first  CI  (SP2  FPG100 
Aft  HB  Drive  Shaft),  are  considerably  above  the  current 
settings.  Indeed  this  particular  CI  was  a  problem  because 
of  the  low  threshold  settings  which  created  numerous 
false  alarms. 

As  seen  in  Figure  22,  the  user  has  the  option  to  accept 
each  of  the  recommended  settings,  fill  in  (and  accept) 
their  own  settings,  or  do  nothing. 


Aircraft  type:  AH64 

Component:  Drive  Shafts 

SP2  FPG100  AFT  HB  Drive  Shaft 


Limit  type:  Current  Settings:  Recommended  Settings:  Modified  Settings: 


Goal: 

■  15  ■ 

2.4669 

Caution: 

1.5 

2.5363 

■■ 

— ■ 

e  Accept  recommended  settings  for  this  Cl 
e  Accept  modified  settings  for  this  Cl 
<*  Accept  NOTHING!  (Make  no  changes) 


SP2FPG100AFTHB  OA 

Limit  type:  Current  Settings:  Recommended  Settings:  Modified  Settings: 


Goal:  10  3.5876  [ 

Caution:  10  3.7807  ft  jj 


e  Accept  recommended  settings  for  this  Cl 
c  Accept  modified  settings  for  this  Cl 
Accept  NOTHING!  (Make  no  changes) 


Figure  22  CI  detection  threshold  setting 

To  gain  more  insight  into  the  data  the  user  may  bring  up 
additional  plots  for  the  data.  Figure  23  shows  some  of  the 
additional  plots  for  the  first  CI  for  the  Drive  Shaft.  The 
top  shows  the  boxplot  for  the  original  data.  The  bottom 
plot  is  a  histogram  of  that  data.  As  described  previously 
the  boxplot  gives  an  indication  of  the  self  consistency  of 
the  data,  the  spread  of  the  data,  and  a  poor  man’s  detector 
of  outliers.  All  the  data  that  was  used  in  plots  of  Figure  23 
had  previously  been  labeled  as  “good”. 

The  box  plots  contain  sets  up  upside  down  and  right  side 
up  triangles.  The  triangles  are  colored  green,  yellow,  and 
red  and  indicate  the  current  threshold  setting  (the  upside 
down  triangles  that  appear  above  the  center  line  in  the 
plots)  and  the  automatically  generated  thresholds  (the 
right  side  up  triangles  that  appear  below  the  center  line  in 
the  plots).  For  this  particular  CI  as  seen  all  of  the 
recommended  threshold  settings  are  to  the  right  of  the 
current  threshold  settings.  It  is  clear  from  this  plot  why 
false  alarms  would  likely  be  occurring. 

For  the  second  CI  shown  in  Figure  22  (SP2  FPG100  Aft 
HB  OA)  we  can  see  that  the  recommended  settings  are 
much  lower  then  the  current  settings.  Thus  with  the 
current  settings  there  will  be  no  false  alarms,  but  also  no 
detections!  Again  the  recommended  settings  would 
greatly  improve  the  system’s  performance. 
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Cl  Limits 


Aircraft:  AH64 
Component:  Drive  Shafts 
Cl  Name:  SP2  FPG100  AFT  HB  Drive  Shaft 


Boxplot 
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Figure  23  Cl  automated  detection  threshold 

Engine  #2  data  that  has  been  examined  previously. 


Gold  Standard  Data  Set  Development 

As  one  can  imagine,  building  models  from  examples  of 
real  data,  requires  that  the  real  data  be  representative  of 
the  normal  and  fault  classes  that  are  being  considered. 
Miss  labeling  of  data  or  allowing  outlier  points  to  be 
included  as  “good”  points,  results  in  models  that  will  not 
be  good.  Thus  tools  have  been  included  in  the  website  for 
viewing  and  including  new  data  as  it  enters  the  system  to 
be  labeled  as  ‘normal’  or  assigning  a  specific  fault  class. 
This  is  used  in  forming  what  we’ve  called  the  gold 
standard  data  set.  All  new  data  entering  the  system  must 
be  reviewed  by  qualified  personnel  before  being  included 
in  the  gold  standard  database. 

The  Server  has  tools  built  into  it  to  be  able  to  bring  up 
new  data  for  individual  components,  display  that  data 
overlaid  with  current  gold  standard  data.  Some  of  those 
tools  are  described  here.  The  data  and  results  presented  so 
far  have  been  on  data  that  has  been  previously  reviewed 
and  labeled  as  “good”  or  not.  That  same  data  is  presented 
below,  but  before  it  has  been  labeled. 

When  data  first  enters  the  system,  it  is  labeled  “new.”  It  is 
not  known  if  the  data  is  “normal”  or  has  some  known 
fault  condition,  or  is  just  a  bad  data  point  (i.e.  equipment 
turned  off  so  no  vibrations  generated  for  example).  It  is 
up  to  the  engineer  to  apply  a  label  to  the  data.  Figure  24 
shows  a  screen  for  reviewing  and  assigning  as  “good” 
new  data  that  enters  into  the  system.  The  data  is  the  AH64 


In  the  display  shown  the  data  has  been  rank  ordered 
according  to  its  distance  [5]  from  a  single  multi¬ 
dimensional  Gaussian  model  fit  to  a  transformed  version 
of  the  multi-dimensional  Cl  data.  The  transform  converts 
the  data  from  its  original  distribution,  so  that  it  is 
Gaussian  in  each  of  its  Cl  dimensions  [6].  This 
transformation  ensures  a  better  model  fit  to  the  data.  An 
example  of  original  data  and  transformed  data  is  shown  in 
Figure  26.  Ensuring  that  the  data  and  the  form  of  the 
model  fit  are  in  agreement  is  often  overlooked  and  “bad” 
models  usually  result.  That  transformation  becomes  part 
of  the  modeling  information  and  used  for  all  future 
processing  (i.e.  the  data  is  first  transformed,  the  anomaly 
detection  of  other  processing  applied,  and  the  results  are 
transformed  back  into  the  original  domain).  Note  at  the 
bottom  of  the  display,  the  data  can  be  sorted  in  a  variety 
of  other  ways. 

Individual  points  can  be  accepted  or  rejected.  However  a 
more  automated  approach  is  to  use  the  “Rejection 
threshold”  shown  at  the  bottom  of  the  display.  Figure  25 
shows  the  results  of  a  roughly  10%  rejection  rate;  that  is 
that  the  top  10%  of  the  points  that  are  farthest  from  the 
nominal  model  are  rejected.  Those  points  are  colored  red 
in  the  plot;  accepted  points  are  green. 
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Modify  Ciass 
Aircraft:  AH64 

New  points  Component:  Engine  2 
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f*  Accept  f  Reject 

1 86-08992  §|  0.081643 

0.159876 

0.011818  01 -Apr-2082  12:26:20 

E  Accept  C  Reject 

■  86-08992  SI  0.072278 

0.062366 

0.010277  11 -Apr-2002  09:12:42 

&  Accept  r  Reject 
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Figure  24  Golden  data  set  specification 
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Figure  25  Labeled  data 
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Original 


Transformed 


Figure  26  Gaussian  transformation  example 

The  histograms  along  the  diagonals  contain  red  and  green 
bars  that  correspond  to  the  red  and  green  points.  At  this 
point  the  user  can  blow  up  individual  displays,  highlight 
single  points  to  determine  which  tail  number  /  flight  that 
data  was  collected  from,  and  then  pull  up  the  data  as 
originally  collected  for  even  more  detailed  review. 


Once  the  data  has  been  validated,  the  user  pushes  a  button 
to  accept  the  labeling,  and  those  new  samples  will  be 
included  into  the  gold  standard  database.  As  more 
samples  are  collected,  the  automated  portion  of  the 
processing  will  become  more  reliable. 


Data  in  the  tails  of  the  normal  vs.  fault  distributions  will 
start  to  be  filled  in! 


based  on  the  Matlab  and  Simulink  processing 
environment.  IAC  has  developed  an  extensive  set  of 
Matlab  based  tools  that  include  data  import,  vibration 
data  analysis,  performance  and  prediction  models, 
statistical  models,  regime  recognition,  and  reasoning 
tools. 

Collection  of  large  amounts  of  data  is  required  to  capture 
both  normal  and  known  fault  events.  All  the  action  in 
prognosis  occurs  in  the  tails  of  distributions  of  “normal” 
vs.  “fault”  measurements  -  precisely  the  areas  where  not 
much  data  has  been  collected.  This  data  is  required  for 
empirical  model  development  but  also  for  validation  of 
detailed  physics  based  models.  The  tails  are  a  scary  place. 
A  slight  change  in  a  threshold  can  mean  a  drastic  change 
in  times. 

The  VMEP  system  is  an  ideal  data  collection  and 
processing  testbed  for  the  continuing  collection  and 
analysis  of  large  amounts  of  real  data  in  support  of 
automated  diagnostic  and  prognostic  system 
development.  The  VMEP  Server  included  tools  to 
automatically  screen  “normal”  and  known  fault  data  so  as 
to  detect  off-nominal  events  that  are  of  interest.  It 
includes  tools  to  systematically  and  continuously  update 
existing  model  parameters  to  improve  overall  detection 
and  classification  performance. 


7 .  Summary  and  Recommendations 

The  US  Army  has  fielded  a  prototype  system  for 
monitoring  of  Army  helicopter  vibration,  with  expansion 
to  include  engine  performance,  and  aircraft  structures. 
The  processing  being  fielded  was  developed  as  part  of  the 
Army’s  Vibration  Management  Enhancement  Program 
(VMEP). 
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